In using a multi-core processor, having a plurality of homogeneous or heterogeneous operating systems run thereon is a useful approach to improve the reliability and responsiveness of the system as a whole.
On the other hand, there is a challenge for such approach in implementing shared use among the plurality of operating systems (hereinafter, “OSs”) running on the multi-core processor of a variety of peripheral devices, including DMA controllers, graphic accelerators, multimedia-dedicated engines, HDDs and controllers (hereinafter collectively, “devices”). This is because the role of an OS to manage device is a closed loop within the OS and, therefore, devices under management of a particular OS are not expected to be accessed by other OSs.
One method for shared use of devices among a plurality of OSs is a client-server approach as disclosed in Non-patent Literature 1 and Non-patent Literature 2. The client-server approach limits the number of OSs that can access devices to one, and causes a server task, which is called an “access server,” to run on that OS. Tasks on the other OS(s) communicate with the access server via inter-OS communication to delegate accesses to devices to the access server. The access server is also called a “proxy” because it performs the role of accessing devices.    Non-Patent Literature 1: Masato EDAHIRO et al., “Development, and Application to Cell Phone, of Software Platform for Multi-core System,” NIKKEI ELECTRONICS, Mar. 28, 2005, pp. 125-136    Non-Patent Literature 2: Junji SAKAI et al., “Software Platform for Embedded Multi-core Processor,” Information processing, Vol. 47, No. 1, Information Processing Society of Japan, January 2006, pp 29-33
However, the client-server approach disclosed in Non-patent Literature 1 and Non-patent Literature 2 has a few drawbacks as described below.
The first drawback is a reduction in the performance of device access via a server, because every time a request for device access is submitted to a server, the current task needs to be switched to the proxy, or the access server. This drawback is particularly problematic with such devices as graphic accelerators and HDDs, to which the speed of access is of critical importance.
The second drawback is high development cost, because the approach requires a function that serves as a proxy to be implemented in access server for each of the different types of device access.
For example, it is not rare that several tens, or even several hundreds, of APIs (Application Program Interfaces) are provided for application developers to access a multi-functional device like a graphic accelerator or HDD. In such a case, the cost required for developing proxies for these APIs and stab routines that are routed through these proxies may sometimes mount to an inhibiting level.